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© In complex networks, data frames may be routed 
through different systems having different frame or 
addressing requirements. When the frames are 
transferred or bridged between such systems, known 
changes may have to be made in the frame contents 
to accommodate these requirements. To maintain 
the integrity of error checking provided by Cyclical 
Redundancy Checking (CRC) techniques, a system 
receiving frame modifies a Frame Check Sequence 
(FCS) field value only as a function of the known or 
planned changes to be made in the frame. If unplan- 
ned changes, that is errors, are introduced at the 
receiving system, application of standard CRC error 
checking techniques at the next system to receive 
the frame will indicate those errors. 



Q. 
UJ 



FRAME 



r 



CALCULATE FCS* 
FOR RECEIVED 
MESSAGE WITH 
STANDARD cpc 
ALGORITHM 



FIG. 6 




CREATE DUMMY 
MESSAGE AS 
ffgHANGES 
TP BE MADE) 



ERROR, FOLLOW 
ERROR HAMOUNQ 
PROTOCOLS 



CALCULATE FCGtm) 
FOR DUMMY 
WITH STANDARD 
CRC ALOORTTHM 



^34 



TAKE 1*8 

OFFCSto) 



ADO RESULT TO 



CHANGE MESSAGE I 



TRANSMIT NEW U^*° 
FRAME WITH 



Xerox Copy Centre 



SDOCID: <EP 03S6589A2_I_> 



EP 0 366 589 A2 



METHOD OF MAINTAINING INTEGRITY OF DATA DURING MESSAGE TRANSMISSION IN A DATA COMMU- 
NICATION SYSTEM 



The present invention relates to data commu- 
nications systems and more particularly to a meth- 
od of maintaining the integrity of cyclical redun- 
dancy checking (CRC) error protection where data 
is intentionally changed at one or more intermedi- 
ate points on the data path between a source and a 
destination. 

A data communications network can be thought 
of as a collection of separate data processing sys- 
tems which may be connected to form a data path 
between a first end user at one system and a 
second end user at another system. 

Data to be transmitted through a network is 
almost always organized in discrete units called 
frames. A frame normally has recognizable bit pat- 
terns at the beginning and end. These bit patterns, 
commonly called delimiters, are used by a receiv- 
ing system to identify the start and the end of each 
frame._AJypical frame also has a header which 
includes the address of the system to which the 
data is to be sent (the destination system) and the 
address of the system from which the data is sent 
(the source system). The frame can also include 
routing information for setting up paths through the 
network between the source and destination sys- 
tems. 

To enable a destination system to determine 
whether errors have been introduced into the data 
during transmission through the network, each 
frame may include a frame check sequence or 
FCS field. The original value of the FCS field is 
established at the source system by applying a 
predetermined mathematical algorithm to selected 
fields in the frame. The results of the algorithm are 
written into the FCS field. When the frame arrives 
at the destination system, that system applies the 
same algorithm to the same fields and compares 
the results with the value of the FCS field con- 
tained in the received frame. If the FCS value 
generated by the destination system and the FCS 
field value in the received frame are the same, it 
assumed the data has been received without error. 

In a complex network, different systems may 
use different formats for a data frame. When data 
is transferred into a system having a different 
frame format, the contents of the fields used in • 
calculation of the original FCS field value may 
intentionally be changed by the receiving system. 

Although the actual data within the frame may 
not change during frame format conversion oper- 
ations, any system which subsequently receives a 
converted frame will be unable to perform normal 
error checking using the frame FCS field value as 
described above. This is because the system re- 



ceiving the converted frame will generate its own 
FCS field value using the same algorithm and the 
same fields as were used by the source system in 
establishing an original FCS field value. If the con- 
5 tents of those fields have been changed (even 
intentionally) at some point along the data path, the 
receiving system can be expected to generate an 
FCS field value different from the original FCS field 
value calculated by the source system. The mis- 
70 match between calculated and received FCS field 
values would falsely indicate an error in the actual 
data in the received frame. 

It has been suggested that this problem can be 
avoided by having each intermediate system on a 
is data path recalculate the FCS field value once the 
format changes have been made. The recalculated 
FCS field value would be inserted in the frame 
before the frame is passed on to the next system. 
Although this approach permits a greater de- 
20 gree of error checking than the approach originally 
described, it still has inadequacies.' In implement- 
ing the "FCS recalculation" approach, each receiv- 
ing system necessarily performs at least three se- 
quential operations involving a data frame. First, 
25 the receiving system checks the incoming data 
frame for errors by calculating its own FCS field 
value and comparing it to the FCS field value in the 
received frame. Second, the receiving system 
changes certain fields in the frame to convert the 
30 frame to the new format. Third, the receiving sys- 
tem recalculates the FCS field value based upon 
the changed frame. 

This sequential three step process leaves the 
data unprotected against errors introduced after the 
35 first step is completed but before the third step is 
performed. If an error is introduced into the data 
during this time period, the FCS field value cal- 
culated during the third step will not in any way 
reflect or indicate that error since the presumption 
40 is that FCS field value calculations are being per- 
formed on error free data. Assuming no further 
errors are introduced, error checking operations 
performed at subsequent receiving systems will 
falsely indicate that the data contained in the frame 
45 is free of errors. 

It has also been suggested that each frame 
being transferred into a system using a different 
frame format be encapsulated or enveloped within 
the frame structure appropriate for the receiving 
so system. An FCS field value would be generated for 
the encapsulating frame. One drawback to this ap- 
proach is that the encapsulation is necessary only 
if the data originates in a system having a different 
frame format. The receiving system must be able 
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to treat incoming frames differently, depending on 
where these frames come from. This requirement 
adds to the complexity of the data transmission. 

The present invention is a method of establish- 
ing an FCS field value in a data frame which 
permits detection of errors introduced into the data 
at intermediate systems. The method preserves the 
error checking value of the FCS field while avoiding 
the complexity of the encapsulating technique 
mentioned above. 

According to the present method, an FCS field 
value is calculated at a source system or station for 
the data by applying a predetermined cyclical re- 
dundancy checking algorithm to selected fields in 
each frame. At each intermediate station on a path 
between the source station and the destination 
station, the field value is modified to reflect planned 
or intentional changes to be made by that station in 
selected fields of the frame. If unintended changes 
(that is, errors) are introduced into the selected 
fields, those changes are not reflected in the modi- 
fied FCS field value since the modification is based 
solely on intended or planned changes in the data. 
Therefore, when the next station on the path 
checks the integrity of the frame by calculating its 
own FCS field value based on selected fields in the 
frame and comparing its FCS value to the received 
FCS value, the difference in the two values will 
indicate the presence of an error or errors in the 
data. 

Details of a preferred embodiment of the inven- 
tion may be more readily ascertained from the 
following technical description when read in con- 
junction with the accompanying drawings wherein: 

Figure 1 is a simple block diagram of a data 
communications network employing systems which 
may have different frame formats, 

Figure 2 depicts the frame format employed 
in one known type of local area network, 

Figure 3 depicts the frame format employed 
in a high speed network employing optical fibers, 

Figure 4 is a table of terms corresponding to 
the abbreviations employed in Figures 2 and 3, 

Figure 5 is a flow chart of a known prior art 
process for producing FCS field values when inten- 
tional changes are to be made in a data frame, 

Figure 6 is a flow chart of a preferred em- 
bodiment of the present invention, and 

Figure 7 is a flow chart setting forth in some 
detail conventional steps performed in calculating 
FCS or frame check sequence values. 

Figure 1 discloses a data communications net- 
work consisting of a number of local area networks 
10, 12, 14 and 16 which may be interconnected 
through an intermediate higher speed or backbone 
network 18. It should be noted that the term net- 
work is used both to refer to the individual local 
area networks, backbone network and the overall 



combination of these individual networks; i.e., the 
data communications networks. Which network is 
being referred to will be clear from the context in 
which the word is used. 

s There are different kinds of local area net- 

works. For purposes of illustration, it will be as- 
sumed that the local area networks 10, 12, 14 and 
16 are token ring networks of a particular type. In 
this type of token ring network, devices such as 

to terminals, peripherals, cluster controllers and com- 
puters are connected to a single continuous ring or 
shared data transmission media. Different types of 
media, such as cable or twisted-pair copper wire, 
may be used for the ring. Optical fibers may also 

75 be used as ring media where high data rates or 
substantial immunity against electromagnetic inter- 
ference or signal attenuations are required. 

In a specific type of token ring network, a 
circulating electronic token passes sequentially 

20 from one node or device to the next around the 
ring, allowing each node an opportunity to transmit 
data. A node having data to transmit can "capture" 
the token and "expand" that token into a frame 
which is circulated around the ring. Each node 

25 receives the frame but only the node or nodes to 
which it is addressed make use of the frame data. 
When the frame returns to the original source 
node, that node must remove the frame from the 
ring and issue a token to allow other nodes in the 

30 ring the opportunity to transmit. 

A limited number of devices or nodes can be 
supported on a single local area network of this 
type. To expand the number of supported devices 
or nodes, individual local area networks can be 

35 interconnected through the high speed backbone 
network 18. The physical and logical connections 
between two networks are referred to as the bridge 
between the two networks. 

One example of a high speed or backbone 

40 network is an FDDI (Fiber Distributed Data Inter- 
face) network which uses optical fibers as a trans- 
mission medium and which supports data rates 
several times greater than the data rates that are 
employed In other typical local area networks. An 

45 FDDI network can also be characterized as a token 
passing network. One of the significant differences 
between an FDDI network and the token ring net- 
work described above is that an FDDI station or 
node originating a frame sends out a token at the 

50 end of that frame. That is, the originating node 
does not wait for the frame to return before issuing 
the token. FDDI networks are described in draft 
standards issued by an ANSI (American National 
Standards Institute) X3T9.5 committee. The details 

55 of the standard are not, however, critical to an 
understanding of the present invention. In fact, the 
present invention is not limited to particular kinds 
of networks. 
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Token ring local area networks and FDDI net- 
works employ different frame formats. Figure 2 
depicts a frame format employed in a token ring 
network complying with current requirements set 
forth by Committee 802.5 of the IEEE (Institute of 
Electrical & Electronics Engineers) organization. 
The frame consists of a number of fields which can 
be classified as starting frame sequence fields, 
header fields, data fields, a frame check sequence 
or FCS field and ending frame sequence fields. 
The starting frame sequence fields include an 8-bit 
SO or starting delimiter field, which Is a recogniz- 
able bit pattern identifying the start of the data 
frame. The AC or access control field is also an 8- 
bit field having several distinct subfields used for 
different functions. The subfields establish the pri- 
ority of a token, distinguish between a frame and a 
token (which is actually an abbreviated frame), con- 
trol whether certain tokens or frames remain on the 
ring and set the priority to be accorded the next 
token to be issued. 

The header fields include an 8-bit FC or frame 
control field which designates a frame either as a 
MAC (Medium Access Control) or a LLC (Logical 
Link Control) frame. MAC frames are used for 
control purposes while LLC frames transport user 
data. The header also has a 48-bit DA or destina- 
tion address field containing the address of the 
user to which the data is to be sent and a 48-bit SA 
or source address field containing the address of 
the source user. The starting frame sequence fields 
and header fields of the frame are sometimes 
collectively referred to as a physical header. 

The frame also includes data fields, inciuding 
an Rl or routing information field containing data 
used to establish a path through the network. The 
Rl or routing information is one of two variable 
length fields in the frame. The other variable length 
field is the INFO field, which contains the actual 
data being transmitted from a source to a destina- 
tion. The data fields are followed by a 32-bit frame 
check sequence or FCS field which is used for 
error checking purposes. The manner in which the 
FCS field value is calculated is discussed in great- 
er detail below. It should be noted, however, that 
the FCS field value is determined by the data 
contained in the message (header and data) portion 
of the frame. Each frame ends with ending frame 
sequence fields consisting of an 8-bit ending de- 
limiter and an 8-bit frame status field. The ending 
delimiter is, of course, recognized by the receiving 
system as an end-of-frame indicator. Different bits 
in the frame status field serve different functions. 
One bit. initially set to 0 by the originating node is 
set to 1 by any intermediate node which detects an 
error, other bits, also originally O's, are set to 1 by 
any station which recognizes its own address and 
which copies the frame into its receive buffer. 



The frame format employed in an FDDI net- 
work meeting ANSI X3T9.5 standards is similar in 
many respects to the token ring frame format. 
Referring to Figure 3, an FDDI frame includes a 
s starting delimiter, a message, a frame check se- 
quence and an ending frame sequence. Unlike a 
token ring frame, however, an FDDI frame is pre- 
ceded by a variable length preamble at least 64 
bits long. Also, while the FDDI header includes a 

w frame control field along with destination and 
source address fields, the frame control field for 
the FDDI frame has a different structure than the 
frame control field for a token ring frame notwith- 
standing each field is 8 bits long. As noted above, 

75 the first two bits of a token ring frame control field 
identify the frame as a LLC or MAC frame. Bits 3-5 
of a token ring frame control field are reserved (and 
thus are always set to zeros) while bits 6-8 are 
indicative of the priority to be given the frame at its 

20 destination. In an FDDI system, the first bit of the 
frame control field establishes whether the FDDI 
frame is an asynchronous frame. The second bit 
establishes whether the FDDI frame includes a 48- 
bit address or not. Bits 3-4 serve the same function 

25 as bits 1-2 of the token ring frame control field in 
identifying whether the frame is an LLC or a MAC 
frame. In the FDDI frame control field, bit 5 is 
reserved while bits 6-8 establish the destination 
system priority level. 

30 Because an LLC or MAC frame is identified by 

different bits in frame control fields used for token 
ring and FDDI frames, respectively, the content of 
the frame control field is necessarily different de- 
pending whether the frame is being routed through 

35 a token ring network or an FDDI network. Because 
the frame control field is part of the message on 
which FCS field values are based, the differences 
in the frame control field must be reflected in any 
error checking process. 

40 Figure 5 is a flow chart of one type of prior art 

process used to alter the FCS field when planned 
or intentional changes are made to the frame mes- 
sage during bridging from one type of network to 
another. 

45 After the frame is received (operation 60) in the 

network, standard error checking operations are 
performed. These operations, identified as block 
62, require that the receiving system calculate an 
FCS field value FCS' by applying a standard cycl- 

50 ical redundancy checking or CRC algorithm to the 
message portion of the received frame. The receiv- 
ing system must determine (operation 64) whether 
a computed value FCS' is consistent with the FCS 
field value found in the received frame. A lack of 

55 consistency between the calculated value FCS' and 
the received value FCS indicates an error in the 
received message. Normal error handling protocols 
are followed (block 66) when an error is detected. If 
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operation 64 indicated that FCS' was consistent 
with the received FCS field value, however, the 
receiving station would then process the received 
frame by changing the message (operation 68). 
The changes in the message may involve nothing 
more than substituting the frame control field re- 
quired by the receiving system for the frame con- 
trol field in the received frame. The receiving sys- 
tem would then calculate operation 70) a new FCS 
field value FCS* by applying the standard CRC 
algorithm to the changed message. The frame 
could then be transmitted through the receiving 
system operation 72) with the newly calculated 
FCS field value FCS". 

As noted earlier, there is a time interval during 
the processing of the frame in which the message 
contents are effectively unprotected. That time in- 
terval occurs between the completion of operation 
64 and the calculation of FCS in operation 70. If 
errors are introduced into the message during this 
time interval, FCS* is calculated using the erro- 
neous message. The next system to receive the 
frame will not, however, be able to detect the error 
since both the FCS field calculated at the next 
system and the FCS field in the frame received at 
that system will be based on the same erroneous 
message. 

To eliminate the periods of time during which 
data is unprotected, the process illustrated in Fig- 
ure 6 can be employed. Certain steps in the pro- 
cess to be described are identical to corresponding 
steps in the prior art process. For example, the 
system must obviously receive a frame (operation 
24) before any further processing can take place. 
The system will preferably also check for errors in 
the incoming frame by applying the standard CRC 
algorithm to the message portion of the frame to 
derive a calculated FCS field value FCS' (operation 
26). The system will also check for consistency 
between the calculated FCS field value and the 
received FCS field value in operation 28 to invoke 
error handling protocols (operation 30) if an in- 
consistency is detected. At this point the present 
method becomes quite different from the prior art 
method. 

The present method does not totally recalcu- 
late the frame check sequence field value but in- 
stead modifies the existing FCS value as a function 
of the planned or intentional message changes. To 
accomplish this, the receiving system creates a 
"dummy" message in an operation 32. This dum- 
my message contains the same number of bits as 
the message portion of the frame (the header fields 
plus the data fields) but represents only, the 
planned changes to be made in the received mes- 
sage. In most instances, one or two bits in the 
frame control field may be changed in the mes- 
sage when a frame is bridged from a token ring 



network to a FDDI network or vice versa. Specifi- 
cally, a frame control field for an LLC token ring 
frame, which is the only type of frame that is 
commonly bridged to another network, will take the 
5 form FC = 01000YYY where YYY represents the 
frame priority. A frame control field for the same 
LLC frame in an FDDI network will take the form 
FC = 01010YYY. Since the priority of the frame 
does not change during bridging, it can be seen 
10 that only one bit in the frame control field must 
necessarily be changed when the frame is trans- 
ferred from a token ring to an FDDI network. Spe- 
cifically, the fourth bit in the frame control field 
must be changed from 0 to 1 . If the frame is being 
is transferred from the FDDI network to a token ring 
network, the same bit must be set from 1 to 0. 

The binary form of the "dummy" message can 
be established through simple binary or modulo-2 
arithmetic. To provide a specific example, if a 
20 frame being transferred from a token ring network 
to an FDDI network had a message area (header 
plus data) 256 bits long, in a simple case, the only 
difference between the message in the token ring 
and the FDDI networks would be in the fourth bit of 
25 the frame control field. The fourth bit would be 
converted from a 0 in the token ring frame to a 1 in 
the FDDI frame. For this type of frame conversion, 
the dummy message would also be 256 bits long. 
In the final form of a message to be transferred in 
30 an FDDI network, the fourth bit of the frame control 
field would be a 1. In a token ring network, the 
same bit would be a zero. Because of the specific 
operations performed by the standard CRC algo- 
rithm, this single bit change can only be accom- 
35 plished by creating a dummy message in which 
the first thirty-two bits are the Vs complement of 
the actual modulo 2 difference between the FDDI 
frame and the corresponding token ring frame. 
That is. bits 1-3 and 5-32 are set to 1 in the 
40 dummy while bit 4 is set to zero. Assuming no 
changes are to be made in the message except in 
the frame control field, the remaining bits of the 
dummy message would be set to 0. 

In accordance with the present invention, an 
45 FCS field modifier is calculated in an operation 34 
by applying the standard CRC algorithm (operation 
34) to the 256 bit dummy message and (to comply 
with IEEE standards) by taking the Vs complement 
(operation 35) of the result The result of operation 
so 35 is an FCS(m) value. Jn an operation 36, a 
modified FCS value FCS" is then calculated by 
adding FCS(m) to the FCS value in the received 
frame, using modulo 2 arithmetic operations. 

While use of a standard CRC algorithm is 
55 envisioned, non-standard algorithms can be em- 
ployed provided any algorithm used is a linear 
mathematical algorithm. A linear mathematical al- 
gorithm is one that satisfies the equation f(A + B) = 
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f(A)+f(B) where f is indicative of a mathematical 
function while A and 8 are data. 

When the modified FCS field value FCS* has 
been calculated and the message has been 
changed (operation 38) as planned, the converted 
frame can be transmitted (operation 40) to the next 
system on the data path. Since the FCS field value 
is modified during conversion only as a function of 
planned changes, any errors introduced into the 
message are not factored into the modified FCS 
value. When the frame is received at the next 
system on the data path, the standard CRC error 
checking operation should reveal an inconsistency 
between the FCS field value calculated at that 
system and the rnodified FCS value received with 
the frame. 

A standard or conventional CRC algorithm is 
briefly described with reference to Figure 7. The 
number of bits in the message portion of the frame 
(the header plus data) must be determined in an 
operation 42 in order to calculate an FCS field 
value. A Variable B is then set equal to the product 
of Xk and a polynomial X31 + X30 + X29 + ... + 
X + 1 where the number of terms in the polyno- 
mial is equal to the number of bits in the FCS field. 
A second variable C is calculated (operation 46) as 
the remainder resulting from modulo 2 division of 
variable B by a standard Generating Polynomial. 

According to existing IEEE standards, the Gen- 
erating Polynomial takes the form X32 + x 26 + 
X23 + X22 + X16 + X12 + X1T + X10 + X8 + 
X7 + X5X4 + X2 + X+ 1. A fourth variable D is 
computed in operation 48 as the product of Xm 
and the binary representation of the frame mes- 
sage treated as a polynomial where m is the length 
of the frame check sequence field in bits. A vari- 
able E is calculated in operation 50 as the remain- 
der resulting from a modulo 2 division of variable D 
by the Generating Polynomial described above. A 
variable G is set equal to the modulo 2 sum of the 
computed variables C and E in operation 52 and 
the frame check sequence field value is set to the 
1 's complement of the variable G in an operation 
54. 

The process described above is used on the 
original data message at the source station. At 
each intermediate station at which the message is 
to be changed, normally by changing the frame 
control field, the Figure 7 process is applied only to 
the dummy message representing the planned 
changes to be made in the message. 

The preceding discussion has assumed that 
the invention may be used beneficially in situations 
where a receiving system performs frame format 
conversions. The invention may also be used in 
any other situation in which planned changes are to 
be made in a frame at a receiving station. For 
example, in a socalled frame relay system, each 



system receiving a frame may strip its own ad- 
dress from one of the fields of the frame and may 
substitute the address of the next system which is 
to receive the frame. The changes in the address 

s field are known, of course, to the system doing the 
address conversion. The present invention may be 
used to maintain continuous CRC error protection 
in such a frame relay system. 

While there has been described what is consid- 

io ered to be a preferred embodiment of the inven- 
tion, variations and modifications in that embodi- 
ment will occur to those skilled in the art once they 
become aware of the basic concepts of the inven- 
tion. Therefore, it is intended that the appended 

is claims shall be construed to include not only the 
preferred embodiment but all such variations and 
modifications as fall within the true spirit and scope 
of the invention. 

20 

Claims 

1. A method of maintaining integrity of data 
contained in data frames being routed along a path 

25 through a data communications system, in which 
data frames are transferred from a source station to 
a destination station through one or more inter- 
mediate stations and, predetermined changes are 
made in each data frame at an intermediate station; 

30 said method comprising the steps of: 

applying a predetermined algorithm to each frame 
at the originating station to calculate a frame check 
sequence value (FCS), and 

modifying the frame check sequence value at each 
35 intermediate station on the path by 

applying the same algorithm to planned changes in 
the selected fields at the intermediate station to 
derive a frame check sequence modifier (FCS (m)) t 
and 

40 modifying the frame check sequence value con- 
tained in the frame received at the intermediate 
station as a function of the value of said modifier, 
thereby permitting the next station to detect data 
errors introduced at the intermediate station. 

45 2. The method as defined in Claim 1 wherein 

the step of deriving the frame check sequence 
modifier further comprises the steps of: 
determining the number of bits k in the selected 
fields, 

so calculating a first variable equal to the product of 
xk and (xm-1 xm-2 + xm-3 + ... x + 1) where m 
is the number of bits in the frame check sequence 
value, 

calculating a second variable equal to the remain- 
55 der resulting from division of the first variable by a 
predetermined polynomial, 
setting a third variable equal to the product of xm 
and the value of the selected fields expressed as a 
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polynomial, 

calculating a fourth variable equal to the remainder 
resulting from division of the third variable by the 
predetermined polynomial, 
summing the second and fourth variables, 
taking the 1 's complement of results of said sum- 
ming step, and 

taking the 1's complement o the results of the 
immediately preceding step. 
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